home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP032992.ARJ / 03-29-92.TPC
Text File  |  1992-03-29  |  80KB  |  2,328 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       03-22-92 18:08:23
  6. From       Trevor Carlsen
  7. To         Thomas Horsten
  8. Subject    Hacker Mark Strikes Back
  9.  
  10.  
  11.  
  12.  TH> If you want to hack the network, why don't you make a TSR that records 
  13.  
  14.  TH> keystrokes to memory? Then just load it on the victims computer in an 
  15.  
  16.  TH> unattended moment, and ... The way you're describing is likely to be 
  17.  
  18.  TH> discovered by the supervisor -- that is, if s/he is not heavily 
  19.  TH> mentally retarded!
  20.  
  21. Promoting illegal activities is not acceptable in this echo.  Any future message
  22.  such as this will result in your echo access being withdrawn.
  23.  
  24. If you wish to reply to this do so by netmail only.
  25.  
  26. Trevor Carlsen
  27. Moderator.
  28.  
  29. --- TC-ED   v2.01  
  30.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  31.  * Tossed by SFToss v1.00b on 92/03/22  21:26:36
  32.  
  33. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  34.  
  35. Conference 4
  36. Date       03-22-92 18:14:58
  37. From       Trevor Carlsen
  38. To         Jud Mccranie
  39. Subject    Re: Reading from a text f
  40.  
  41.  
  42.  
  43.  GE> Could you post an example of how to search for certain text
  44.  GE> within a text file?  Thanks.
  45.  
  46.  JM> Is the file small enough to fit in memory (<64K)?  If so then
  47.  JM> something like
  48.  JM> { untested code!!! }
  49.  JM> var line : array [ 1 .. 750] of string[ 80];
  50.  
  51. The trouble with using a method like this is that it will not work unless
  52. the text files have no lines exceeding 80 characters and the text being searched
  53. for does not span any line.  Far better to use an algorithm such as Boyer-Moore
  54. and search the complete file rather than lines.
  55.  
  56. TeeCee
  57.  
  58. --- TC-ED   v2.01  
  59.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  60.  * Tossed by SFToss v1.00b on 92/03/22  21:26:36
  61.  
  62. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  63.  
  64. Conference 4
  65. Date       03-22-92 18:28:31
  66. From       Trevor Carlsen
  67. To         Michael George III
  68. Subject    PASCAL and ORDINAL DATA TYPES
  69.  
  70.  
  71.  
  72.  MG> I am a seasoned C programmer learning PASCAL for the sake of writing 
  73.  
  74.  MG> some BBS utilities for the TAG BBS software. I understand the use of 
  75.  
  76.  MG> records, but what I don't understand is the use of RECORDS within 
  77.  MG> RECORDS...
  78.  
  79.  MG>   Filerec = (        {File flags}
  80.  MG>     NotValidated,      {File is not validated}
  81.  MG>     OwnerRestricted,   {Uploader did not receive credit on upload}
  82.  MG>     uuF6,              {Reserved}
  83.  MG>     uuF5,              {Reserved}
  84.  MG>     uuF4,              {Reserved}
  85.  MG>     uuF3,              {Reserved}
  86.  MG>     uuF2,              {Reserved}
  87.  MG>     uuF1               {Reserved}
  88.  MG>     ); {1 byte used for 8 flags in set}
  89.  
  90.  MG>   FlagRecSet = SET OF Filerec; {Set of file flags}
  91.  
  92.  MG> What I need to understand is how to read/modify the UlfRec.Flag field. 
  93.  
  94.  MG> What sort of data type is it? What operations can be performed on it. 
  95.  
  96.  MG> How can I set a BIT to either the ON or OFF position?
  97.  
  98. UlfRec is a type - not a variable.  So somewhere there will be a variable
  99. defined as a UlfRec.  The type FlagRecSet is a set and it is this that is
  100. being used to set bits.  
  101.  
  102. Let's assume the variable (record) of type UlfRec is called UlfRecVar  then
  103. to set bit 0 of UlfRecVar.flag -
  104.   UlfRecVar.flag := UlfRecVar.flag + [NotValidated];
  105.  
  106. TeeCee
  107.  
  108. --- TC-ED   v2.01  
  109.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  110.  * Tossed by SFToss v1.00b on 92/03/22  21:26:36
  111.  
  112. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  113.  
  114. Conference 4
  115. Date       03-23-92 02:12:41
  116. From       
  117. To         
  118. Subject    
  119.  
  120.  --- DB B1061/002070
  121.  * Origin: Host 206/0 -=- public image -=- 018-551878 (2:206/0)
  122.  * Tossed by SFToss v1.00b on 92/03/23  07:09:28
  123.  
  124. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  125.  
  126. Conference 4
  127. Date       03-22-92 02:36:55
  128. From       Mark Ouellet
  129. To         Duke Normandin
  130. Subject    Re: TurboBBS
  131.  
  132.  
  133.     On 12 Mar 92, you, Duke Normandin, of 1:134/49.0 wrote...
  134.  
  135.  >>        I think he drowned off the coast of some foreign country ;-)
  136.  
  137.  DN> Is this a joke?
  138.  
  139. What do YOU think ??? ;-)
  140.  
  141.         Best regards,
  142.         Mark Ouellet.
  143.  
  144.  
  145. P.S. Don't you read the news paper ???
  146.  
  147. --- ME2
  148.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  149.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  150.  
  151. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  152.  
  153. Conference 4
  154. Date       03-22-92 02:37:33
  155. From       Mark Ouellet
  156. To         Tom Przeor
  157. Subject    Re: Pkunzip to nul
  158.  
  159.  
  160.     On 13 Mar 92, you, Tom Przeor, of 3:640/821.0 wrote...
  161.  
  162.  MO>> RH>>Why using a COMMAND environment and not just starting
  163.  MO>> RH>>pkunzip by searching for the right path thru fsearch ?
  164.  
  165.  MO>> RH>>EXEC(fexpand(fsearch('PKUNZIP.EXE',getenv('PATH'))), 'test.zip
  166.  MO>> RH>> >NUL');
  167.  
  168.  MO>> TP> You need command processor for redirection to work, your method 
  169.  
  170.  MO>> is
  171.  MO>> TP> fine but '>NUL' won't work.
  172.  
  173.  MO>>OOPS missed that one when I replied to him ;-)
  174.  
  175.  TP> No, you haven't. He just asked why you've used COMMAND.
  176.  
  177. Exactly Tom,
  178.         If you look at the quote you'll notice I wasn't the
  179. one who indicated the need for the Command processor in
  180. order to get redirection. I had missed the '>' sign and
  181. agreed with him that using the fexpand would work. In fact
  182. his comment ie: "Why use command..." was not a question but
  183. rather an indication of his surprise that someone would use
  184. the command processor to execute a program. He missed the
  185. redirection part as I did when I gave him credit for using
  186. Fexpand instead of the GetEnv('COMSPEC') to locate the
  187. executable file.
  188.  
  189.  
  190.         Best regards,
  191.         Mark Ouellet.
  192.  
  193. --- ME2
  194.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  195.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  196.  
  197. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  198.  
  199. Conference 4
  200. Date       03-22-92 02:43:27
  201. From       Mark Ouellet
  202. To         Jud Mccranie
  203. Subject    Re: TP 6.0 IDE memory
  204.  
  205.  
  206.     On 13 Mar 92, you, Jud Mccranie, of 1:370/520.0 wrote...
  207.  
  208.  MO>> BTW if you can't adapt to the 6.0 IDE, don't despair,
  209.  MO>> Borland Pascal++ is just around the corner ;-)
  210.  
  211.  JM> That's what I've heard.  I hope they take the users into
  212.  JM> consideration this time.  They were headed in the wrong direction
  213.  JM> w/ 6.0 IDE, IMHO.
  214.  
  215. Jud,
  216.         It is a matter of personnal taste but I guess in a
  217. little while you'll learn to love the 6.0 IDE and probably
  218. KILL anyone who tries to take it away from you ;-)
  219.  
  220.         I have rarely seen Borland make mistakes. In fact
  221. I've pretty much allways been able to predict their moves.
  222. They usually base any novelty on their user's requests. No
  223. company could survive otherwise. I guess with the Windows
  224. version they confused sales reports with actual usage of the
  225. thing. Lot's of people bought it but very few are actualy
  226. using it. In fact I was glad that the Borland representative
  227. that presided the seminar here in Quebec city acknowledge
  228. that fact. They had surveyed the users and promised that
  229. since so many people "Hated windows" (His words, not mine)
  230. that they would continue producing products for the DOS
  231. market.
  232.  
  233. I sure hope the next IDE still runs from DOS.
  234.  
  235.         And when I multitask I use DesqView, I want the
  236. multitasked programs to grab the power, not the multitasker.
  237.  
  238. BTW, keep your old messages, when Borland Pascal comes out
  239. you'll probably just have to edit them and replace any
  240. reference of "5.5" with "6.0" and "6.0" with "1.0" or
  241. whatever they number this one. <Verrrrrryyyy big grin>
  242. Then we'll just start the thread over again ;-)
  243.  
  244.         Best regards,
  245.         Mark Ouellet.
  246.  
  247. --- ME2
  248.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  249.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  250.  
  251. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  252.  
  253. Conference 4
  254. Date       03-22-92 03:00:14
  255. From       Mark Ouellet
  256. To         Ken Koch
  257. Subject    Re: Another "Help me"
  258.  
  259.  
  260.     On 14 Mar 92, you, Ken Koch, of 1:208/2.0 wrote...
  261.  
  262.  KK> John,
  263.  KK> Yes. DIR strips out the "."... You can also do this by using 
  264.  KK> FINDFIRST
  265.  KK> & stripping out the 9th character.
  266.  
  267. Ken,
  268.         Actually it's the other way around, DOS adds the '.'
  269. when listing filenames. It just doesn't add it for volume
  270. labels.
  271.  
  272.         Best regards,
  273.         Mark Ouellet.
  274.  
  275.  
  276.  
  277. --- ME2
  278.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  279.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  280.  
  281. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  282.  
  283. Conference 4
  284. Date       03-22-92 04:10:41
  285. From       Mark Ouellet
  286. To         James Stanley
  287. Subject    Re: Mouse/graphics
  288.  
  289.  
  290.     On 13 Mar 92, you, James Stanley, of 1:231/440.0 wrote...
  291.  
  292.  JS> Would you happen to use RIME and have an XX3401 encoder so you could
  293.  JS> post it here?
  294.  JS> 
  295.  JS> James Stanley
  296.  
  297. James,
  298.         converted source or code files such as those sent
  299. through XX3401 or UUencode or anyother such processor is
  300. forbiden on this echo.
  301.  
  302.         The moderator explicitly included this rule into the
  303. echo's policy list after the idea of using the echo as an
  304. upload/download route was proposed. The traffic is high
  305. enough without cluttering it with such stuff.
  306.  
  307.         BTW if it was permitted then you wouldn't be getting
  308. all those neat Pascal sources. Why bother posting the Source
  309. when you can compile and post the UUencoded TPU.
  310.  
  311.         Best regards,
  312.         Mark Ouellet.
  313.  
  314. --- ME2
  315.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  316.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  317.  
  318. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  319.  
  320. Conference 4
  321. Date       03-22-92 04:16:59
  322. From       Mark Ouellet
  323. To         Greg Smith
  324. Subject    Re: Tpascal mags.
  325.  
  326.  
  327.     On 12 Mar 92, you, Greg Smith, of 1:110/69.0 wrote...
  328.  
  329.  GS> Yo DUDE!!!!!!! Please stop sending me messages I have absolutly no 
  330.  GS> interest in pascal or whatever the !@$%@*@!!@$#^*$ you are talking 
  331.  GS> about.  On top of that I don't even know who you are.
  332.  GS> thanks for the understanding.
  333.  GS> Greg smith
  334.  
  335. Yo Greg,
  336.         learn the ways of echo-mail before replying. Jud was
  337. sending a message to "GREG SMITH" ok so... there are
  338. probably hundreds if not thousands of "GREG SMITH" in the
  339. world and this is a world wide conference.
  340.  
  341.         Remember that your BBS can not know WHICH "GREG
  342. SMITH" the message was sent to so it marks it as being for
  343. you since the names match.
  344.  
  345.         Best regards,
  346.         Mark Ouellet.
  347.  
  348. --- ME2
  349.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  350.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  351.  
  352. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  353.  
  354. Conference 4
  355. Date       03-22-92 17:39:12
  356. From       Mark Ouellet
  357. To         Dj Murdoch
  358. Subject    Re: TP 6.0 disassembler...
  359.  
  360.  
  361.     On 16 Mar 92, you, Dj Murdoch, of 1:221/177.40 wrote...
  362.  
  363.  DM> That's 14.4 HST, but I've heard from
  364.  DM> Europeans that they have trouble connecting, so watch out that you don't 
  365.  
  366.  DM> make a lot of wasted phone calls.
  367.  
  368. Dj,
  369.         Were you by any chance refering to my 150 $Can of
  370. connect attempts to Australia ;-) ?!?
  371.  
  372. BTW I'll try to contact the sysop of 1:3/1 to route my
  373. NetMail to zone 3 through his node, should allow me to
  374. NetMail TeeCee or any one else in zone 3.
  375.  
  376.         Best regards,
  377.         Mark Ouellet.
  378.  
  379. --- ME2
  380.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  381.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  382.  
  383. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  384.  
  385. Conference 4
  386. Date       03-22-92 17:43:58
  387. From       Mark Ouellet
  388. To         Jud Mccranie
  389. Subject    Re: Why I Like Tp 5.5 Ide (continued)
  390.  
  391.  
  392.     On 17 Mar 92, you, Jud Mccranie, of 1:370/520.0 wrote...
  393.  
  394.  JM> P.S. I just changed the "O" color, and that brought out another major
  395.  JM> problem.  After I made the change and did "OK" it poped me back into
  396.  JM> the editor.  I assumed that it had made the change, but NOOOO!!!  You
  397.  JM> have to exit from the editor again and go over to options and tell it
  398.  JM> to save the options.  You shouldn't have to do all of that.  If you
  399.  JM> OKed it, it should save it.  Baring that, it should at least keep you
  400.  JM> in the options menu.
  401.  
  402. Jud,
  403.         You boviously don't like the way this works but I
  404. prefer to have to TELL the IDE to save the new
  405. configuration. I hate it when a program assumes it is ok to
  406. save any changes unless I tell it to.
  407.  
  408. I sometimes change just a single flag for my compilation and
  409. want the options to return to their original values when I
  410. exit the IDE and come back the next time.
  411.  
  412.         Best regards,
  413.         Mark Ouellet.
  414.  
  415.  
  416.  
  417. --- ME2
  418.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  419.  * Tossed by SFToss v1.00b on 92/03/22  10:59:41
  420.  
  421. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  422.  
  423. Conference 4
  424. Date       03-22-92 18:17:43
  425. From       Mark Ouellet
  426. To         Jacob Zielinski
  427. Subject    Re: md and dwc archive formats
  428.  
  429.  
  430.     On 16 Mar 92, you, Jacob Zielinski, of 1:153/9.0 wrote...
  431.  
  432.  JZ> Does anyone know what programs are used to un-archive "md" and 
  433.  JZ> "dwc"
  434.  JZ> files, or what the file formats are?
  435.  
  436. Jacob,
  437.         DWC uses DWC.EXE as for MD files I haven't
  438. encountered them yet.
  439.  
  440. BTW Where on earth did you find DWC compressed files ????,
  441. I've had the unarchiver for close to a year I think but have
  442. yet to encounter a .dwc file.
  443.  
  444.         Best regards,
  445.         Mark Ouellet.
  446.  
  447.  
  448.  
  449. --- ME2
  450.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  451.  * Tossed by SFToss v1.00b on 92/03/22  10:59:42
  452.  
  453. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  454.  
  455. Conference 4
  456. Date       03-22-92 18:39:33
  457. From       Mark Ouellet
  458. To         Joy Mukherjee
  459. Subject    Custom caracter sets
  460.  
  461.  
  462. Hi Joy,
  463.         Just wanted you to know I was interrested in your
  464. postings but unfortunately only message 1 of 4 made it
  465. through here. The three missing messages are not even in my
  466. DUPE section so I guess they got dumped upstream from my
  467. system.
  468.  
  469. Is there any chance you might repost.??
  470.  
  471.         Best regards,
  472.         Mark Ouellet.
  473.  
  474. --- ME2
  475.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  476.  * Tossed by SFToss v1.00b on 92/03/22  10:59:42
  477.  
  478. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  479.  
  480. Conference 4
  481. Date       03-22-92 23:01:40
  482. From       Mark Ouellet
  483. To         Joy Mukherjee
  484. Subject    Re: Qwk Format/reader 1/3
  485.  
  486.  
  487.     On 15 Mar 92, you, Joy Mukherjee, of 1:387/255.0 wrote...
  488.  
  489.  JM> {$V-}
  490.  JM> 
  491.  JM> { PROGRAM QWK READER - Written by Joy Mukherjee }
  492.  JM> {         Donated to the Public Domain          }
  493.  JM> 
  494.  JM> Program ReadQWKRepFile;
  495.  JM> 
  496.  JM> uses Crt;
  497.  JM>
  498.  < STUFF DELETED FOR SPACE >
  499.  
  500.  >>>> Continued to next message
  501.  
  502. No it didn't
  503.  
  504. Joy,
  505.         this is another example of the problem, 2/3 et 3/3
  506. never made it here. Could you repost please ???
  507.  
  508.         Best regards,
  509.         Mark Ouellet.
  510.  
  511.  
  512.  
  513. --- ME2
  514.  * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  515.  * Tossed by SFToss v1.00b on 92/03/22  10:59:42
  516.  
  517. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  518.  
  519. Conference 4
  520. Date       03-23-92 17:15:44
  521. From       Trevor Carlsen
  522. To         Dj Murdoch
  523. Subject    Variable # parameters
  524.  
  525.  
  526.  
  527.  DM> ... Those names are hard coded
  528.  DM> into a part of the RTL for which you don't get source...
  529.  
  530. I'm interested in this explanation you gave re write/writeln/read/readln.
  531.  I don't think that this an accurate statement.  All the RTL's source for
  532. input/output appears to be in my copy of the RTL.
  533.  
  534. Admittedly there are no procedures named write/writeln...etc. But that is
  535. because they do not in fact exist!  It appears to me that the compiler parses
  536. such statements into their respective parts - WriteFloat, WriteStr, WriteInt,
  537. WriteBool, WriteChar, WriteLine, WriteEnd, WriteFile, ReadFloat, ReadStr,
  538. ReadInt, ReadChar, ReadLine, ReadEnd.  (Have I missed any?)
  539.  
  540. I have not bothered to really examine this closely and you may well correct
  541. me but that is the way it appears to me.  It also makes sense to me that it
  542. is done this way.
  543.  
  544. TeeCee
  545.  
  546.  
  547. --- TC-ED   v2.01  
  548.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  549.  * Tossed by SFToss v1.00b on 92/03/22  18:24:16
  550.  
  551. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  552.  
  553. Conference 4
  554. Date       03-23-92 17:07:43
  555. From       Trevor Carlsen
  556. To         Dj Murdoch
  557. Subject    Re: Exponentiation (was: Are you...)
  558.  
  559.  
  560.  
  561.  DM> I think type complex was in the standard.  I don't know if anyone is 
  562.  
  563.  DM> going to add it to a real compiler, but I'd guess VAX Pascal.  They 
  564.  DM> seem to be the big standard supporters.
  565.  
  566. I'm just quoting on a job which specifies - DOS is to be version  MS-DOS version
  567. 5 and the programs are to be written and compiled using ANSI standard Pascal.
  568.  
  569. Ever heard of such a beast?  (The alleged reason for the ANSI standard Pascal
  570. is to allow easy upgrade to OS/2.)  Tried talking to the Manager today but
  571. got nowhere... seems he is a civil engineer and a friend has impressed on
  572. him the desirability of sticking to "the standard".  When I suggested he may
  573. have meant ISO, he was adamant - it had to be ANSI. 
  574.  
  575. Grrrr... I wish the job was small enough to just say "stick it..." but it
  576. isn't.
  577.  
  578. TeeCee
  579.  
  580. --- TC-ED   v2.01  
  581.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  582.  * Tossed by SFToss v1.00b on 92/03/22  18:24:16
  583.  
  584. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  585.  
  586. Conference 4
  587. Date       03-23-92 19:28:00
  588. From       Norbert Igl
  589. To         Joseph Crea
  590. Subject    INPUT ROUTINE/LIMITED LENGTH--CORRECTION
  591.  
  592.  
  593.  
  594.  
  595.   Hi Joseph, that's a good one !
  596.  >   DOS.MsDos(regs); (* make DOS function call *)
  597.  >   for j := 0 to 254 do   (* copy to x *)
  598.  >      x[j] := buffer[j];
  599.  
  600.    ... why do you copy only 254 Chars?
  601.    ... why 254 at all?
  602.     try this instead:
  603.  
  604.     move(buffer[0], x[0], BYTE(Buffer[0]));
  605.  
  606.     it's faster, and copies only the # of entered chars..
  607.  
  608. Bye from Germany, Norbert
  609.  
  610. ---
  611.  * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  612.  * Tossed by SFToss v1.00b on 92/03/24  07:01:54
  613.  
  614. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  615.  
  616. Conference 4
  617. Date       03-24-92 21:00:00
  618. From       Werner Berghofer
  619. To         Peter Kling
  620. Subject    Traffic report
  621.  
  622.  
  623.  
  624.  
  625.  
  626.        Peter,
  627.  
  628.  > I like it a lot, If it works on hudson style message base
  629.  > I would like to make use of it on my echo's that I moderate..
  630.  
  631.        here's the output for this conference from a similar program I wrote
  632. a while back -- of course in Turbo Pascal.  It works on a Hudson style message
  633. base and requires no additional configuration if used in a Frontdoor/Tosscan
  634. environment.
  635.  
  636.  
  637.    ----------------------------------------------------------------------
  638.    Who writes most messages?                         "Pascal programming"
  639.    first: Tue, 3 Mar 1992; 0:00             last: Mon, 23 Mar 1992; 19:28
  640.    ----------------------------------------------------------------------
  641.    Jud McCranie .............................................. 155   8.5%
  642.    Dj Murdoch ................................................  84   4.6%
  643.    Gerald Gutierrez ..........................................  81   4.5%
  644.    Ruurd Pels ................................................  73   4.0%
  645.    Trevor Carlsen ............................................  70   3.9%
  646.  
  647.    /* Lots of lines deleted */
  648.  
  649.    The Admiral ...............................................   2   0.1%
  650.    Thomas Groff ..............................................   2   0.1%
  651.    Tony Weeks ................................................   2   0.1%
  652.    Wayne Moses ...............................................   2   0.1%
  653.    Zak Smith .................................................   2   0.1%
  654.    ----------------------------------------------------------------------
  655.  
  656.  
  657.    ----------------------------------------------------------------------
  658.    Who receives most messages?                       "Pascal programming"
  659.    first: Tue, 3 Mar 1992; 0:00             last: Mon, 23 Mar 1992; 19:28
  660.    ----------------------------------------------------------------------
  661.    All ....................................................... 184  10.1%
  662.    Jud McCranie .............................................. 138   7.6%
  663.    Gerald Gutierrez ..........................................  64   3.5%
  664.    Dj Murdoch ................................................  57   3.1%
  665.    Trevor Carlsen ............................................  50   2.8%
  666.  
  667.    /* Lots of lines deleted */
  668.  
  669.    Terry Towle ...............................................   2   0.1%
  670.    Thomas Groff ..............................................   2   0.1%
  671.    Todd Armstrong ............................................   2   0.1%
  672.    Yvo Van Musscher ..........................................   2   0.1%
  673.    Zak Smith .................................................   2   0.1%
  674.    ----------------------------------------------------------------------
  675.  
  676.  
  677.    ----------------------------------------------------------------------
  678.    Overview of message topics                        "Pascal programming"
  679.    first: Tue, 3 Mar 1992; 0:00             last: Mon, 23 Mar 1992; 19:28
  680.    ----------------------------------------------------------------------
  681.    Turbo Pascal 6.0 IDE ......................................  53   2.9%
  682.    Why I like Turbo Pascal 5.5 IDE more than 6.0 .............  51   2.8%
  683.    Pascal vs. C ..............................................  35   1.9%
  684.    New reader! ...............................................  32   1.8%
  685.    Pascal structure philosophy ...............................  32   1.8%
  686.  
  687.    /* Lots of lines deleted */
  688.  
  689.    Test ......................................................   2   0.1%
  690.    Turbo Pascal Internal Error ...............................   2   0.1%
  691.    Turbo Pascal user groups? .................................   2   0.1%
  692.    Ultraforce Demo ...........................................   2   0.1%
  693.    VGA 512 ...................................................   2   0.1%
  694.    ----------------------------------------------------------------------
  695.    messages total ............................................1818
  696.    days covered in report ....................................  21
  697.    average number of messages per day ........................  86.6
  698.    ----------------------------------------------------------------------
  699.  
  700.  
  701.      Special awards for this review
  702.    ----------------------------------------------------------------------
  703.    * The "Why type it myself?" award goes to Jud McCranie
  704.      for "Why I like Turbo Pascal 5.5 IDE more than 6.0",
  705.      dated Fri, 20 Mar 1992; 1:48.
  706.      An incredible 93.0 percent of this message were quotes.
  707.  
  708.    * The "Keep it short and sweet" award goes to Scott Sanbar
  709.      for the message regarding "Test",
  710.      dated Mon, 23 Mar 1992; 3:10.
  711.      Never was there more said with ten characters.
  712.  
  713.    * The "Nostalgia" award goes to Htraffic V. 1 0
  714.      for the message regarding "Traffic Report",
  715.      dated Sat, 21 Mar 1992; 8:53.
  716.      Not one of those 11188 characters was quoted.
  717.    ----------------------------------------------------------------------
  718.  
  719.  
  720.    The ten most active users of this message area
  721.    ----------------------------------------------------------------------
  722.    Jud McCranie ..................... [14.0 messages/day] ... 293  16.1%
  723.    Gerald Gutierrez ................. [ 6.9 messages/day] ... 145   8.0%
  724.    Dj Murdoch ....................... [ 6.7 messages/day] ... 141   7.8%
  725.    Ruurd Pels ....................... [ 5.8 messages/day] ... 121   6.7%
  726.    Trevor Carlsen ................... [ 5.7 messages/day] ... 120   6.6%
  727.    Richard Morris ................... [ 3.2 messages/day] ...  68   3.7%
  728.    Joshua Kersey .................... [ 2.4 messages/day] ...  50   2.8%
  729.    Mike Copeland .................... [ 2.2 messages/day] ...  46   2.5%
  730.    Mike Krejci ...................... [ 2.1 messages/day] ...  45   2.5%
  731.    Kelly Small ...................... [ 2.1 messages/day] ...  44   2.4%
  732.    ----------------------------------------------------------------------
  733.    active participants total ................................. 378
  734.    ----------------------------------------------------------------------
  735.  
  736.  
  737.                average message posting frequency per day
  738.    ----------------------------------------------------------------------
  739.     0:00- 1:59 ************************************                  8.3%
  740.     2:00- 3:59 *********************                                 4.9%
  741.     4:00- 5:59 ******                                                1.4%
  742.     6:00- 7:59 *********************                                 4.8%
  743.     8:00- 9:59 *****************************************             9.3%
  744.    10:00-11:59 ***************************************************  11.6%
  745.    12:00-13:59 ********************************************         10.1%
  746.    14:00-15:59 *********************************************        10.2%
  747.    16:00-17:59 *******************************************          10.0%
  748.    18:00-19:59 *******************************************           9.8%
  749.    20:00-21:59 ******************************************            9.7%
  750.    22:00-23:59 *******************************************          10.0%
  751.    ----------------------------------------------------------------------
  752.  
  753.  
  754.                average message posting frequency per week
  755.    ----------------------------------------------------------------------
  756.    Monday      ******************************                       10.2%
  757.    Tuesday     **************************************               12.9%
  758.    Wednesday   *************************************                12.5%
  759.    Thursday    ******************************************           14.3%
  760.    Friday      ************************************************     16.3%
  761.    Saturday    ***************************************************  17.0%
  762.    Sunday      **************************************************   16.8%
  763.    ----------------------------------------------------------------------
  764.  
  765.  
  766.        Look around for a file called "Qlist150.*", it should be available
  767. also in your zone.
  768.  
  769.        Werner.
  770.  
  771. ---
  772.  * Origin: God is real... unless declared integer. (2:310/90.100)
  773.  * Tossed by SFToss v1.00b on 92/03/25  07:45:03
  774.  
  775. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  776.  
  777. Conference 4
  778. Date       03-23-92 19:12:00
  779. From       Terry Hughes
  780. To         Dj Murdoch
  781. Subject    Re: Binary Tree Linked L
  782.  
  783.  
  784. DM>Thanks.  I think I've heard that before, but I forgot it.
  785. DM>Why don't they just call them Bayer-Trees?
  786.  
  787. Beats me -- maybe it's too hard to spell.
  788.  
  789. Based on the excerpts that Jud quoted the definition of B-Tree
  790. we use doesn't seem to be as wide spread as I had thought.
  791.  
  792. -Terry
  793.  
  794.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  795.  
  796. --- Maximus 2.01wb
  797.  * Origin: The Programmers Playhouse (1:128/60)
  798.  * Tossed by SFToss v1.00b on 92/03/25  13:09:24
  799.  
  800. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  801.  
  802. Conference 4
  803. Date       03-24-92 13:06:57
  804. From       Trevor Carlsen
  805. To         Jud Mccranie
  806. Subject    Re: Tp 6.0 Ide
  807.  
  808.  
  809.  
  810.  TC> You have either misunderstood or chosen to misinterpret what I
  811.  TC> have said. It is *essential* in testing any application that
  812.  TC> you *do* hit the design limits.
  813.  
  814.  JM> Well, then, testing in the IDE is a good idea, because you will
  815.  JM> hit (memory) limits there sooner than w/o the IDE.  If you don't
  816.  JM> hit the limit in the IDE you won't in DOS (unless the target machine
  817.  JM> is really loaded down with TSRs in conv. mem.)
  818.  
  819. I'm glad it was the first and not the second.  :-)
  820.  
  821. The limits you refer to are a valid test of course but it is of little consolati
  822. n if that limit is reached before the *program's* design limit. It is just
  823. as important to test that as well - often more so, as it is frequently algorithm
  824. dependant.
  825.  
  826. TeeCee
  827.  
  828. --- TC-ED   v2.01  
  829.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  830.  * Tossed by SFToss v1.00b on 92/03/25  13:09:24
  831.  
  832. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  833.  
  834. Conference 4
  835. Date       03-24-92 19:43:29
  836. From       Trevor Carlsen
  837. To         Mark Dixon
  838. Subject    Re: Hacking the Network
  839.  
  840.  
  841.  
  842.  TC> Take this thread somewhere else.  The subject of this conference 
  843.  
  844.  MD> My original message was asking for TP routines for Novell network 
  845.  MD> programming, so I think that it IS in the right place. The other 
  846.  MD> messages derrived from that
  847.  
  848. The original thread was perfectly acceptable.  The thread that developed with
  849. the above subject is  not only off-topic but is illegal in some countries.
  850.  I requested you to stop that thread.  More by netmail.
  851.  
  852. Trevor Carlsen
  853. Moderator.
  854.  
  855. --- TC-ED   v2.01  
  856.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  857.  * Tossed by SFToss v1.00b on 92/03/25  13:09:27
  858.  
  859. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  860.  
  861. Conference 4
  862. Date       03-24-92 20:17:04
  863. From       Trevor Carlsen
  864. To         All
  865. Subject    virus
  866.  
  867.  
  868.  
  869.  MD> Yes, a virus can be written in Turbo Pascal. Read around some of the 
  870.  
  871.  MD> virus descriptions, there are a few around written in TP. One simply 
  872.  
  873.  
  874.  MD> ... Well, thats an idea I had for a virus, it isn't hard to write.... 
  875.  
  876.  MD> Using TP6 with the FindFirst, FindNext routines it is very easy...
  877.  
  878. I won't bother everyone with details on this but this thread has just claimed
  879. its second victim.  Unfortunately the writer of the above will not be with
  880. us any more and the same will also apply to anyone who wishes to continue
  881. to answer the thread.
  882.  
  883. If you wish to comment on or reply to this message do so by NETMAIL ONLY.
  884.  
  885. Trevor Carlsen
  886. Moderator.
  887.  
  888.  
  889.  
  890. --- TC-ED   v2.01  
  891.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  892.  * Tossed by SFToss v1.00b on 92/03/25  13:09:27
  893.  
  894. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  895.  
  896. Conference 4
  897. Date       03-24-92 20:30:21
  898. From       Trevor Carlsen
  899. To         Darren Lyon
  900. Subject    Entry to competition
  901.  
  902.  
  903.  
  904.  DL>    Here is my _first_ entry to your programming competition. ...
  905.  
  906. Thanks Darren.  Unfortunately at this time it is ineligible as you have copyrigh
  907. ed it.  If you still wish to have it entered it *must* be placed in the public
  908. domain with no rights reserved.
  909.  
  910.  DL>    Has there been much response to the competition?
  911.  
  912. Not as yet although there have been several indications that entries are forthco
  913. ing before June.
  914.  
  915. TeeCee
  916.  
  917.  
  918. --- TC-ED   v2.01  
  919.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  920.  * Tossed by SFToss v1.00b on 92/03/25  13:09:27
  921.  
  922. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  923.  
  924. Conference 4
  925. Date       03-24-92 21:02:32
  926. From       Trevor Carlsen
  927. To         All
  928. Subject    Off-topic messages
  929.  
  930.  
  931.  
  932. Recently there has been a surge of off-topic messages and of users who are
  933. responding to off-topic messages.
  934.  
  935. Some of those responding to these messages are those who should know better...
  936. eg.  Long time readers and users of the echo.
  937.  
  938. Please help us maintain the viability of this echo by reducing the signal-noise
  939. ratio and DO NOT ANSWER off-topic messages.  I answer most of these messages
  940. by netmail so rest assured they are not being ignored.
  941.  
  942. Another disturbing development is the number of messages on viruses and network
  943. hacking.  I WILL arbitarily cut off echo access to users who continue to ignore
  944. my requests to drop these subjects.  Sysops expend a great deal of money,
  945. time and effort in developing their systems for your benefit.  They do not
  946. deserve to have all this put at risk by thoughtless, irresponsible users enterin
  947.  messages which could give the Federal Police grounds for confiscation of
  948. equipment.
  949.  
  950. The fact is, rightly or wrongly, that in the USA and Australia (and possibly
  951. other countries also), Federal police DO have these powers of seizure if BBSs
  952. carry advice on committing illegal acts.  Please consider this before entering
  953. messages.
  954.  
  955. Trevor Carlsen
  956. Moderator.
  957.  
  958.  
  959.  
  960. --- TC-ED   v2.01  
  961.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  962.  * Tossed by SFToss v1.00b on 92/03/25  13:09:27
  963.  
  964. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  965.  
  966. Conference 4
  967. Date       03-24-92 21:21:18
  968. From       Trevor Carlsen
  969. To         Devon Ellis
  970. Subject    Reading Ansi
  971.  
  972.  
  973.  
  974.  DE> The easiest way is to put ANSI.SYS in your autoexec.bat file, then 
  975.  DE> include DIRECTVIDEO := FALSE somewhere near the begining of the code.  
  976.  
  977.  DE> You can then just write the data to the screen and let ANSI.SYS do all 
  978.  
  979.  DE> the translating for you.
  980.  
  981. This is completely incorrect.
  982.  
  983. ANSI.SYS is a driver that must be loaded via config.sys and setting DirectVideo
  984. to false will have no effect whatsoever on whether the ANSI.SYS driver gets
  985. control.
  986.  
  987. Either do not use the CRT unit or place the following lines somewhere early
  988. in the program:
  989.  
  990. assign(output,'');
  991. rewrite(output);
  992.  
  993. This ensures all output is handled through dos and thus ansi.sys will be used.
  994.  
  995. TeeCee
  996.  
  997. --- TC-ED   v2.01  
  998.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  999.  * Tossed by SFToss v1.00b on 92/03/25  13:09:27
  1000.  
  1001. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1002.  
  1003. Conference 4
  1004. Date       03-24-92 21:27:49
  1005. From       Trevor Carlsen
  1006. To         Devon Ellis
  1007. Subject    Screen Save
  1008.  
  1009.  
  1010.  
  1011.  DE> type
  1012.  DE>   Screenpoint= array[1..2000] of record
  1013.  DE>       character:char;
  1014.  DE>       attribute:byte;
  1015.  DE>   end;
  1016.  DE>  
  1017.  DE> var point: ^screenpoint;
  1018.  DE>     Newpoint: ^screenpoint;
  1019.  DE>  
  1020.  DE> and then later on say something like 
  1021.  DE>  
  1022.  DE> if lastmode = mono then point := ptr($B000,0000) 
  1023.  DE>         else point := ptr($B800,0000);
  1024.  DE>  
  1025.  DE> Then if you wish to save it to disk, you can use the command
  1026.  DE>  
  1027.  DE>     BLOCKWRITE(diskfile,point,1);  {where diskfile is an untyped  
  1028.  DE> where diskfile is a file of the form  DISKFILE:FILE that you have 
  1029.  DE> already assigned and opened and everything.  To move the screen to 
  1030.  DE> another location in memory, try 
  1031.  DE>  
  1032.  DE>  NEW(Newpoint);  {establishes a free spot in memory for data)
  1033.  DE>  MOVE(point,newpoint,4000);
  1034.  DE>  
  1035.  DE> which should move all 2000 records from one location to the other.
  1036.  
  1037. Very dangerous and incorrect advice.  When using pointers in this way they
  1038. MUST be dereferenced.  The best that could happen with your code is that the
  1039. machine would lock up, the worst doesn't bear thinking about.
  1040.  
  1041. Your idea is perfectly valid of course and is used extensively.  Just remember
  1042. that pointers MUST be dereferenced when accessing data that they reference
  1043. otherwise disaster follows.
  1044.  
  1045. TeeCee
  1046.  
  1047. --- TC-ED   v2.01  
  1048.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1049.  * Tossed by SFToss v1.00b on 92/03/25  13:09:28
  1050.  
  1051. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1052.  
  1053. Conference 4
  1054. Date       03-25-92 23:04:21
  1055. From       Dj Murdoch
  1056. To         Jud Mccranie
  1057. Subject    Re: TP 6 Bad design
  1058.  
  1059.   JM> No.  I ran it from RAM disk.  Moreover, there is a timer inside the
  1060.  JM> program that does the timing in that case, so the program has already
  1061.  JM> loaded and started running when it sets the time to 0, etc.
  1062.  
  1063. It sounds as though you did the timings in a reasonable way, then.  I don't
  1064. understand at all why you'd observe what you did.  I've never observed that
  1065. 6.0 was slower than 5.5; generally the tests I did put them pretty close,
  1066. with a slight edge to 6.0.  
  1067.  
  1068. Are you using third party libraries?  Perhaps the 6.0 versions aren't as good
  1069. as the 5.5 libraries. 
  1070.  
  1071. --- Msg V3.2
  1072.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1073.  * Tossed by SFToss v1.00b on 92/03/26  10:56:00
  1074.  
  1075. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1076.  
  1077. Conference 4
  1078. Date       03-25-92 23:09:56
  1079. From       Dj Murdoch
  1080. To         Gerald Gutierrez
  1081. Subject    Re: C+ vs Turbo Pascal
  1082.  
  1083.   > If for no other reason than Turbo
  1084.  > Pascal is much less expensive than Borland C++, though Borland's Turbo
  1085.  > C++ is also inexpensive.  I think, however, that with Turbo Pascal you
  1086.  
  1087.  GG> Only 800 bucks Canadian last time I checked the paper ( 
  1088.  GG> for Borland C++ 3.0 ).. 8(
  1089.  
  1090. Order it from the States by mail order:  $US469 plus about $40 shipping for
  1091. BC++ with AF, from the Connection, 800-336-1166.  I've had better luck ordering
  1092. from them than direct from Borland:  most U.S. companies don't understand
  1093. international shipping at all well.  I don't know why you'd want to order
  1094. a compiler that weighs 18 pounds, though :-).
  1095.  
  1096. --- Msg V3.2
  1097.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1098.  * Tossed by SFToss v1.00b on 92/03/26  10:56:00
  1099.  
  1100. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1101.  
  1102. Conference 4
  1103. Date       03-25-92 23:15:52
  1104. From       Dj Murdoch
  1105. To         Jud Mccranie
  1106. Subject    Re: Variable # parameters
  1107.  
  1108.   DM> so that
  1109.  DM> you can just add parentheses to your heart's content
  1110.  
  1111.  JM> don't remind me of LISP or I may ge BESERK!
  1112.  
  1113. Hey, looks like I'm going to have to learn LISP.  I was just at a conference
  1114. where a very nice experimental statistical package was demo'd - XLISP-STAT.
  1115.  Trouble is, it's based on LISP.  Luckily, it understands DLLs when it's running
  1116. under Windows, so I'm hoping to do all the numerical stuff in TPW.
  1117.  
  1118. --- Msg V3.2
  1119.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1120.  * Tossed by SFToss v1.00b on 92/03/26  10:56:00
  1121.  
  1122. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1123.  
  1124. Conference 4
  1125. Date       03-25-92 23:26:14
  1126. From       Dj Murdoch
  1127. To         Jud Mccranie
  1128. Subject    Conditionals (was: Why I Like...)
  1129.  
  1130.   JM>> I sometimes use $IFDEF test, but usually I want to test at that
  1131.  JM>> location only temporarily.  I need to remember to remove it.
  1132.  
  1133.  TC> Why?  That is the whole point of compiler conditionals!
  1134.  
  1135.  JM> After the bug has been fixed then I no longer need that line(s).
  1136.  
  1137. A very good technique (which I generally haven't had the discipline to follow)
  1138. is to put "assertions" into conditional sections of your program, and leave
  1139. them there.  The assertions are things like:
  1140.  
  1141.   Assert(sizeof(X) = sizeof(Y));
  1142.  
  1143. put in just before you use Move to copy X into Y.  What this does is to check
  1144. your assumptions:  if you've made a change to the declaration of X but not
  1145. Y, then your Move will probably introduce a bug into your program.  The Assert
  1146. procedure can be very simple:  something like
  1147.  
  1148.   procedure Assert(assertion:boolean);
  1149.   begin
  1150.     if not Assertion then
  1151.       RunError(199);
  1152.   end;
  1153.  
  1154. would be good enough to point out your error to you, though a fancier version
  1155. would tell you where it occurred.
  1156.  
  1157. When you're debugging, you just pepper your program with assertions until
  1158. one fails, and you've found the bug.  But then you can leave them in, and
  1159. they'll help you later, if you ever make changes that make one of your assumptio
  1160. s faulty.
  1161.  
  1162.   
  1163.  
  1164. --- Msg V3.2
  1165.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1166.  * Tossed by SFToss v1.00b on 92/03/26  10:56:00
  1167.  
  1168. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1169.  
  1170. Conference 4
  1171. Date       03-25-92 23:37:09
  1172. From       Dj Murdoch
  1173. To         Harald Harms
  1174. Subject    Re: ATTENTION!!!
  1175.  
  1176.   HH> As you can see, it's a piece of cake to use! And it 
  1177.  HH> converts to ANY turbo.tpl...!!!!!!!
  1178.  
  1179.  HH> If you are interested, you can NETMAIL me for details on 
  1180.  HH> how to purchace this product. Please note: This product is NOT shareware
  1181.  
  1182. Can't you post the details here?  I think this would be of general interest
  1183. to a lot of people.
  1184.  
  1185. I had one question:  what sort of input .TPU can it accept?  I couldn't tell
  1186. if it was only for converting from TP 6.0 .TPU files from one SYSTEM unit
  1187. to another, or if it could do version conversions as well.
  1188.  
  1189. --- Msg V3.2
  1190.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1191.  * Tossed by SFToss v1.00b on 92/03/26  10:56:00
  1192.  
  1193. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1194.  
  1195. Conference 4
  1196. Date       03-25-92 09:41:30
  1197. From       Trevor Carlsen
  1198. To         Frank Masingill
  1199. Subject    Re: C++ products
  1200.  
  1201.  
  1202.  
  1203.  FM>      I fit that category of being a student of programming and do 
  1204.  FM> emphasize TP, Trevor, but there is another reason I have for learning 
  1205.  
  1206.  FM> some of the rudiments of C and that is simply the joy of the chase and 
  1207.  
  1208.  FM> moreover, I honestly believe that I have discovered some things about 
  1209.  
  1210.  FM> programming in C and Assembler study that help me to understand what 
  1211.  
  1212.  FM> the TP code is doing.  This might be more applicable, though, to 
  1213.  FM> somebody like me who is not taking college courses but trying to learn 
  1214.  
  1215.  FM> from written sources of various kinds, books, this echo, etc.  Not 
  1216.  FM> being a professional does not (grin) keep one from wanting to "have it 
  1217.  
  1218.  FM> all!!"
  1219.  
  1220. And I "dips me lid" to you!  The quest for knowledge need not cease just because
  1221. one has retired or has no real need for that knowledge.  I was not implying
  1222. that :-)  
  1223.  
  1224. BTW - I received your letter - thanks very much for that, I will reply shortly.
  1225.  
  1226. TeeCee
  1227.  
  1228. --- TC-ED   v2.01  
  1229.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1230.  * Tossed by SFToss v1.00b on 92/03/26  23:32:34
  1231.  
  1232. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1233.  
  1234. Conference 4
  1235. Date       03-25-92 08:30:29
  1236. From       Trevor Carlsen
  1237. To         Gary Elfert
  1238. Subject    Re: Reading from a text f
  1239.  
  1240.  
  1241.  
  1242.  -> Download PNL010.* from a BBS near you.  It contains an example of a
  1243.  -> Boyer-Moore search.
  1244.  
  1245.  GE> Thanks, but I don't think any of the local boards have it.  Is there
  1246.  GE> someone I can FREQ it from?   Thanks.
  1247.  
  1248. Any PDN node should have it.  Others closer to you may be able to help.
  1249.  
  1250. TeeCee
  1251.  
  1252. --- TC-ED   v2.01  
  1253.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1254.  * Tossed by SFToss v1.00b on 92/03/26  23:32:35
  1255.  
  1256. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1257.  
  1258. Conference 4
  1259. Date       03-26-92 07:25:21
  1260. From       Trevor Carlsen
  1261. To         Eric Gardiner
  1262. Subject    Reading the screen in TP6
  1263.  
  1264.  
  1265.  
  1266.  EG> Okay all, this is what I'm trying to do...  I need a way to grab the 
  1267.  
  1268.  EG> current screen from within a program and save it to a file.  All this 
  1269.  
  1270.  EG> is strictly text, no graphics.  I successfully accomplished this 
  1271.  EG> through the BIOS, but I'd prefer something quicker.  I know you can 
  1272.  EG> read the screen directly from memory, but when I tried saving it to a 
  1273.  
  1274.  EG> file that way it ended up saving pieces of screens past, a general 
  1275.  EG> mess.  Anybody out there have a code fragment that will do this?  I 
  1276.  EG> used to be fairly fluent in TP, but I'm a bit rusty, so any and all 
  1277.  EG> help would be appreciated.  Thanks!
  1278.  
  1279. In text mode this is easy to do.  All that is required is that you determine
  1280. where the start of video memory is (it is different in mono to what it is
  1281. in colour).  Here is an example:
  1282.  
  1283. First set up some types that can be "mapped" to a screen -
  1284.  
  1285. type
  1286.   VideoCell   = record
  1287.                   character: char;
  1288.                   attribute: byte;
  1289.                 end;
  1290.   VideoScreen = array[1..80,1..25] of VideoCell;
  1291.   VideoPtr    = ^VideoScreen;
  1292.  
  1293. var
  1294.   Screen      : VideoPtr;
  1295.   SavedScreen : VideoScreen;
  1296.  
  1297. begin
  1298.   if LastMode = Mono then
  1299.     Screen := ptr($b000,0)
  1300.   else
  1301.     Screen := ptr($b800,0);
  1302.  
  1303.   { To save a screen }
  1304.   SavedScreen := Screen^;
  1305.  
  1306.   { To restore a saved screen }
  1307.   Screen^ := SavedScreen;
  1308.  
  1309. In anything of this nature, the programmer should be aware that with some
  1310. older types of graphics cards accessing the video RAM directly in this way
  1311. may cause a "snow" effect.  This can be countered by only doing accesses between
  1312. vertical retraces.  As such cards are relatively rare now, most do not bother.
  1313.  
  1314. TeeCee
  1315. --- TC-ED   v2.01  
  1316.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1317.  * Tossed by SFToss v1.00b on 92/03/26  23:32:35
  1318.  
  1319. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1320.  
  1321. Conference 4
  1322. Date       03-26-92 07:39:50
  1323. From       Trevor Carlsen
  1324. To         Tony Phillips
  1325. Subject    BlockRead Command
  1326.  
  1327.  
  1328.  
  1329.  TP> Could someone give me an example of how I would search for information 
  1330.  
  1331.  TP> in an array of records after using a blockread? An example of how to 
  1332.  
  1333.  TP> keep track of the records would also be handy. Any help would surely 
  1334.  
  1335.  TP> be appreciated!
  1336.  
  1337. More information needed.  What sort of records?  What order are they stored
  1338. in? What sort of information will you be looking for?  Can you detail exactly
  1339. how they were read into the array and the declaration of that array?
  1340.  
  1341. TeeCee
  1342.  
  1343. --- TC-ED   v2.01  
  1344.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1345.  * Tossed by SFToss v1.00b on 92/03/26  23:32:36
  1346.  
  1347. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1348.  
  1349. Conference 4
  1350. Date       03-25-92 07:21:01
  1351. From       Mark Cook
  1352. To         All
  1353. Subject    Help!
  1354.  
  1355.  
  1356.  
  1357. I am having BIG problems trying to detect Windows in a dos window! Here is
  1358. the code:
  1359.  
  1360. unit MTKUnit;
  1361.  
  1362. interface
  1363.  
  1364. type
  1365.   MTKTYPE = record
  1366.     installed : boolean;
  1367.     version_maj,
  1368.     version_min : byte;
  1369.     version_str : string[6];
  1370.   end;
  1371.   MTKRECTYPE = record
  1372.     Windows,
  1373.     DesqView: mtktype;
  1374.   end;
  1375.  
  1376. var
  1377.   MTK : mtkrectype;
  1378.  
  1379. implementation
  1380.  
  1381. uses dos;
  1382.  
  1383. Procedure CheckWin;
  1384. var
  1385.   tstr : string[2];
  1386.   regs : registers;
  1387. begin
  1388.   regs.ax := $1600;
  1389.   Intr($2F,regs);
  1390.   case regs.al of
  1391.     $0,$80 : MTK.Windows.Installed := False;
  1392.     $1,$ff : begin
  1393.                MTK.Windows.Installed := True;
  1394.                MTK.Windows.Version_Maj := 2;
  1395.                MTK.Windows.Version_Min := 0;
  1396.                MTK.Windows.Version_Str := '2.0';
  1397.              end;
  1398.   else begin
  1399.     MTK.Windows.Installed := True;
  1400.     MTK.Windows.Version_Maj := lo(regs.ax);
  1401.     MTK.Windows.Version_Min := hi(regs.ax);
  1402.     str(MTK.Windows.Version_Maj,MTK.Windows.Version_Str);
  1403.     str(MTK.Windows.Version_Min,tstr);
  1404.     MTK.Windows.Version_Str := MTK.Windows.Version_Str+tstr;
  1405.   end;
  1406.  end;
  1407. end;
  1408.  
  1409. begin
  1410.   CheckWin;
  1411.  
  1412.   writeln(MTK.Windows.Installed);
  1413.   writeln(MTK.Windows.Version_Str);
  1414. end.
  1415.  
  1416.  
  1417. It just says that windows is NOT installed...Trust me, it is.  In enhanced
  1418. mode, too.  RemoteAccess (the BBS program I use) detects 'Windows 3.0' fine...pl
  1419. ase help me!
  1420.  
  1421. ---
  1422.  * Origin: Wizardry * 300-2400 (303)674-1305 (1:104/630) * HST (1:104/631.0)
  1423.  * Tossed by SFToss v1.00b on 92/03/26  23:33:11
  1424.  
  1425. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1426.  
  1427. Conference 4
  1428. Date       03-25-92 23:59:25
  1429. From       Dj Murdoch
  1430. To         Robert Soubie
  1431. Subject    Re: Are you listening... ?
  1432.  
  1433.   > Trust me .... you want it as an OPERATOR!!
  1434.  
  1435.  RS>     Okay, Okay... If it _has_ to be an operator, so do 
  1436.  RS> sinh, cosh, tanh, and the like. Where should this stop?
  1437.  
  1438. No, those don't need to be operators, for several reasons.  First, standard
  1439. mathematical notation doesn't write them as operators.  If you want a program
  1440. to calculate sinh(4), coding it as
  1441.  
  1442.   x := sinh(4);
  1443.  
  1444. is pretty natural.  Compare that to coding 2 cubed as 
  1445.  
  1446.   x := pow(2,3);
  1447.  
  1448. or
  1449.  
  1450.   x := 2^3;
  1451.  
  1452. or 
  1453.   x := 2**3;
  1454.  
  1455. It seems to me that the latter two are a lot clearer than the first one.
  1456.  
  1457. Second, and related to the first argument, all of those special functions
  1458. only take a single argument.  It's easy to write functions of a single parameter
  1459. as functions. 
  1460.  
  1461. Third, those examples you gave don't need to do any type selection.  You'd
  1462. always want Sinh(x) to convert x to a floating point type (Real or Extended),
  1463. and to return a floating point type.  That's not clear with something like
  1464. 2**3 - should the result be real or integer?  (I think it should be integer,
  1465. the same way that 2*3 is an integer.)
  1466.  
  1467. --- Msg V3.2
  1468.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1469.  * Tossed by SFToss v1.00b on 92/03/27  13:52:13
  1470.  
  1471. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1472.  
  1473. Conference 4
  1474. Date       03-26-92 08:59:51
  1475. From       Dj Murdoch
  1476. To         Gerald Gutierrez
  1477. Subject    DIV bug?
  1478.  
  1479.   GG> Bug #1: ( an obvious known bug, but... ) how would you go about using the
  1480.  
  1481.  GG>         DIV function in basm, while avoiding the Division By Zero error ?
  1482.  
  1483.  GG>         Perhaps I'm just not doing it right -- but I haven't had anyone
  1484.  GG>         correct me on the short code I posted here and there yet, so I
  1485.  
  1486.  GG>         suspect it's the fact that Borland screwed that little part up,
  1487.  GG>         or no one knows asm where I live...
  1488.  
  1489. I didn't see your posting.  Could you repost sample code illustrating the bug?
  1490.  
  1491.  
  1492. --- Msg V3.2
  1493.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1494.  * Tossed by SFToss v1.00b on 92/03/27  13:52:13
  1495.  
  1496. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1497.  
  1498. Conference 4
  1499. Date       03-26-92 09:02:52
  1500. From       Dj Murdoch
  1501. To         Richard Morris
  1502. Subject    Re: Are you listening... ?
  1503.  
  1504.   RM> It would be nice to have operator overloading so we can 
  1505.  RM> create objects (eg: type complex or Matrix) and overload 
  1506.  RM> the standard operators.
  1507.  
  1508. I don't agree.  Operator overloading can easily confuse you - for example,
  1509. there are 3 kinds of matrix products that I know of (element by element multipli
  1510. ation, linear map composition, and tensor product); languages that allow you
  1511. to multiply matrices seem to alternate pretty freely between the first two
  1512. as the meaning of "*".  If you have two routines from different units that
  1513. use "MatMul" with different meanings, it'll be a lot easier to fix than if
  1514. they use "*" with different meanings.
  1515.  
  1516. Complex numbers should be included in the base types, we shouldn't have to
  1517. define those ourselves.  
  1518.  
  1519.  
  1520. --- Msg V3.2
  1521.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1522.  * Tossed by SFToss v1.00b on 92/03/27  13:52:13
  1523.  
  1524. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1525.  
  1526. Conference 4
  1527. Date       03-26-92 09:08:50
  1528. From       Dj Murdoch
  1529. To         Greg Williams
  1530. Subject    Re: Yet another use for streams
  1531.  
  1532.   GW> Hmm... BTW:  Do you happen to know how BIG a stream can go 
  1533.  GW> (ie. maximum size)?
  1534.  GW> Is it constrained by DOS file size, or by the size of a LONGINT, or what?
  1535.  GW> I've been looking into SEEKing into a byte-stream (ie. a 
  1536.  GW> binary file) and find the restrictions a bit of a pain!  
  1537.  
  1538. There's no restriction on the size of a stream that I can think of, but if
  1539. you went beyond longint size, all the Seek, GetSize, GetPos etc. methods would
  1540. fail.  
  1541.  
  1542. Why are you finding the Seek restrictions a pain?  Do you really have streams
  1543. bigger than a longint?
  1544.  
  1545. --- Msg V3.2
  1546.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1547.  * Tossed by SFToss v1.00b on 92/03/27  13:52:13
  1548.  
  1549. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1550.  
  1551. Conference 4
  1552. Date       03-26-92 09:11:23
  1553. From       Dj Murdoch
  1554. To         Jonathon Blake
  1555. Subject    Re: Obsolete Pascal??
  1556.  
  1557.  DM>I'd say that Standard Pascal is close to obsolete right DM> now.  I would
  1558. never DM>use it, nor would I recommend that anyone else use it.  DM> Turbo
  1559. Pascal, on the
  1560.  
  1561.  JB>      except that there are things that can be done with standard pascal
  1562.  JB>     that can not be done with turbo pascal or borland pascal.
  1563.  
  1564.  JB>      now if turbo pascal implemented  get & put
  1565.  JB>      i'd have a better opinion of the language.
  1566.  
  1567. TP is not standard compliant, and the file system is one of the ways it fails.
  1568.  In my opinion, the TP file system is a *better* model of what files are like
  1569. than the standard model.  Get and Put and file pointers don't match my idea
  1570. of files like STDIN and STDOUT; Get and Put are specialized procedures, that
  1571. shouldn't be in the general language.  
  1572.  
  1573. I suspect they're there because Pascal was designed as a teaching language,
  1574. and they make it easy to teach about buffering.  But they're not the way bufferi
  1575. g should really be done. 
  1576.  
  1577. --- Msg V3.2
  1578.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1579.  * Tossed by SFToss v1.00b on 92/03/27  13:52:13
  1580.  
  1581. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1582.  
  1583. Conference 4
  1584. Date       03-26-92 17:39:02
  1585. From       Dj Murdoch
  1586. To         Clayton O'Neill
  1587. Subject    Re: Comercial Programs in
  1588.  
  1589.   -=> Quoting T.j. Laurenzo about Re: Comercial Programs in <=-
  1590.  TL> How about Turbo Pascal 6 itself??? It says in the manual that the IDE
  1591.  TL> was written in Pascal!?!? Anyone got an explanation on how they
  1592.  TL> managed that?
  1593.  
  1594.  CO> It may have been but the version of TVision that they wrote TP6.0 w/is
  1595.  CO> not the version that is distributed.  For example, there are numerous
  1596.  CO> bugs in the TEditor object that are not present in the IDE. And so
  1597.  CO> on....
  1598.  
  1599. It's not clear from the documentation, but Borland has stated that the editor
  1600. in TP 6 is not TEditor.  Other units from TP are included without change in
  1601. TURBO.EXE:
  1602.  
  1603.   DOS
  1604.   DRIVERS
  1605.   OVERLAY
  1606.   SYSTEM
  1607.   
  1608.   COLORSEL
  1609.   STDDLG   ( with some changes )
  1610.   DIALOGS
  1611.   APP
  1612.   MENUS
  1613.   VIEWS
  1614.   HISTLIST
  1615.   MEMORY
  1616.   OBJECTS
  1617.   I think that's all.  I didn't get this list from Borland; I obtained it
  1618. by comparing the code in the .TPU files with that in the .EXE.  STDDLG appears
  1619. to be a slightly different version than the one distributed, mostly in the
  1620. form of constants having different values.
  1621.  
  1622.  
  1623. --- Msg V3.2
  1624.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1625.  * Tossed by SFToss v1.00b on 92/03/27  13:52:13
  1626.  
  1627. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1628.  
  1629. Conference 4
  1630. Date       03-26-92 18:15:33
  1631. From       Dj Murdoch
  1632. To         Jason Hills
  1633. Subject    Re: Why I Like Tp 5.5 Ide (c
  1634.  
  1635.   JH> -- What accounts for the DRASTIC size differences between OPro
  1636.  JH> programs, and a respective Turbo Vision based one?  I expiremented
  1637.  JH> with a friends copy of OPro for a while (after being WELL grounded
  1638.  JH> in Turbo Vision, and OOP in general) and I could NEVER get an .exe
  1639.  JH> out of OPro that as even close the size of the TV one... even tho
  1640.  JH> both had EXACTLY the same functionality.
  1641.  
  1642. I think the main difference is that OPRO is more flexible, and there's no
  1643. way to avoid linking in some code that you may never use.  If you had exactly
  1644. the same functionality, you probably were under-using OPRO.
  1645.  
  1646. That's a valid complaint about OPRO:  the fact that you can't turn off the
  1647. capabilities when you don't need them.
  1648.  
  1649.  
  1650. --- Msg V3.2
  1651.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1652.  * Tossed by SFToss v1.00b on 92/03/27  13:52:14
  1653.  
  1654. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1655.  
  1656. Conference 4
  1657. Date       03-26-92 18:22:24
  1658. From       Dj Murdoch
  1659. To         Jud Mccranie
  1660. Subject    Re: Power of assemb vs Pascal
  1661.  
  1662.   JM> an almost-trivial program in Pascal, using recursion.  I know
  1663.  JM> assembler must be able to do recursion, but probably not easily.
  1664.  JM> It probably requires the programmer to maintain everything.  But
  1665.  JM> the point is that 1. for weeks he never thought of the recursive
  1666.  JM> solution (and it immediately occurred to me), and 2. Pascal is
  1667.  JM> probably more powerful in that respect.
  1668.  
  1669. Assembler can do recursion just as easily as Pascal can.  All you need for
  1670. recursion is a concept of local variables; there's no problem setting those
  1671. up in assembler.
  1672.  
  1673.  
  1674.  
  1675. --- Msg V3.2
  1676.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1677.  * Tossed by SFToss v1.00b on 92/03/27  13:52:14
  1678.  
  1679. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1680.  
  1681. Conference 4
  1682. Date       03-26-92 18:26:32
  1683. From       Dj Murdoch
  1684. To         Gerald Gutierrez
  1685. Subject    Re: Record Const..
  1686.  
  1687.   GG> Can someone perhaps point out the problem to the follow declaration ?
  1688.  
  1689.  GG>     Const
  1690.  GG>       MainMenu : MenuOptionsType =
  1691.  
  1692. Since you didn't give us the MenuOptionsType declaration or any hint as to
  1693. why there's a problem, it's not very easy to help you out here.   
  1694.  
  1695.  
  1696. --- Msg V3.2
  1697.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1698.  * Tossed by SFToss v1.00b on 92/03/27  13:52:14
  1699.  
  1700. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1701.  
  1702. Conference 4
  1703. Date       03-27-92 02:38:00
  1704. From       Werner Berghofer
  1705. To         Jud McCranie
  1706. Subject    Why I like Turbo Pascal 5.5 IDE more tha
  1707.  
  1708.  
  1709.  
  1710.  
  1711.        Jud,
  1712.  
  1713.        [about SAA/CUA:]
  1714.  
  1715.  > It makes all programs look pretty much alike and hard to use.
  1716.  
  1717.        well, after reading for a while in this conference I already got used
  1718. to your self-willed, if not to say obstinate, way of thinking and making harsh
  1719. statements.  However, I wonder if that's really all which you have to say
  1720. regarding such an innovative and useful concept like SAA/CUA.
  1721.  
  1722.        I can't imagine one single computer user which would prefer to learn
  1723. let's say four different keystrokes in four different applications performing
  1724. just the same task: open a file for example.  Using an SAA/CUA application
  1725. even if the program is totally unknown everybody knows how to open a file:
  1726. Alt-F-O, how to print: Alt-P, or how to quit: Alt-X.
  1727.  
  1728.        If you think that means "hard to use" and if you also believe that
  1729. it is a disadvantage for all programs to "look pretty much alike" -- well,
  1730. you obviously never have used an Apple Macintosh.  The success of the Mac's
  1731. user interface really proves that guys with your opinion belong to a minority.
  1732.  
  1733.        People use their computers to get their work done faster and easier,
  1734. but not to study cryptic, arcane and application-specific keystrokes.  It's
  1735. absolute nonsens to open files in WordPerfect with different keystrokes than
  1736. in Microsoft Word (or whatever).
  1737.  
  1738.        Welcome to 1992,
  1739.  
  1740.        Werner.
  1741.  
  1742. ---
  1743.  * Origin: God is real... unless declared integer. (2:310/90.100)
  1744.  * Tossed by SFToss v1.00b on 92/03/27  13:52:28
  1745.  
  1746. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1747.  
  1748. Conference 4
  1749. Date       03-27-92 07:20:00
  1750. From       Werner Berghofer
  1751. To         David G. Edwards
  1752. Subject    Why I like Turbo Pascal 5.5 IDE more tha
  1753.  
  1754.  
  1755.  
  1756.  
  1757.        David,
  1758.  
  1759.  > Why is "Y" associated with "delete" anyway?
  1760.  
  1761.        that's part of the now ancient Wordstar keyboard scheme: E-S-D-X was
  1762. used for the basic cursor movements up-left-right-down.  Keys which are located
  1763. in a greater distance from this "diamond" also trigger "stronger" actions
  1764. than the keys closer to the diamond.
  1765.  
  1766.        Examples: Ctrl-S moves one character to the left, Ctrl-A a whole word.
  1767.  Ctrl-D is one character right, Ctrl-F one word.  Ctrl-G deletes a character,
  1768. Ctrl-T deletes a single word and Ctrl-Y a whole line.  However, this scheme's
  1769. logic is based on an U.S. keyboard layout.  This scheme was developed back
  1770. in The Dark Age as cursor control keys were found seldom on keyboards, but
  1771. Wordmaster and later Wordstar were operable on any keyboard.
  1772.  
  1773.        By the way: it's a funny feeling answering to a message which will
  1774. be posted by you tomorrow ;-)  Any troubles with your system's clock?
  1775.  
  1776.        Werner
  1777.  
  1778. ---
  1779.  * Origin: God is real... unless declared integer. (2:310/90.100)
  1780.  * Tossed by SFToss v1.00b on 92/03/27  13:52:28
  1781.  
  1782. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1783.  
  1784. Conference 4
  1785. Date       03-27-92 01:13:31
  1786. From       Trevor Carlsen
  1787. To         Jim Starke
  1788. Subject    Input Routine
  1789.  
  1790.  
  1791.  
  1792.  JS> I have recieved a lot of help from a lot of people via the echo and if 
  1793.  
  1794.  JS> I have missed responding to someone, I am sorry and thanks for all of 
  1795.  
  1796.  JS> your suggestions!  
  1797.  
  1798. When you ask for assistance in echo mail, thanks for any help received is
  1799. automatically assumed.  It is "bad form" to thank people individually as it
  1800. adds unnecessary costs to the echo.  I don't mind seeing a blanket "thank-you"
  1801. such as the above quote but the rules specifically ask that individual thank-you
  1802. messages be avoided.
  1803.  
  1804. Trevor Carlsen
  1805. Moderator
  1806.  
  1807. --- TC-ED   v2.01  
  1808.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1809.  * Tossed by SFToss v1.00b on 92/03/27  23:27:02
  1810.  
  1811. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1812.  
  1813. Conference 4
  1814. Date       03-27-92 19:56:58
  1815. From       Trevor Carlsen
  1816. To         Jonathon Blake
  1817. Subject    Re: Obsolete Pascal??
  1818.  
  1819.  
  1820.  
  1821.  JB>  ...except that there are things that can be done with 
  1822.  JB> standard pascal that can not be done with turbo pascal 
  1823.  JB> or borland pascal.
  1824.  
  1825.  JB>      now if turbo pascal implemented  get & put
  1826.  JB>      i'd have a better opinion of the language.
  1827.  
  1828. First though a caveat - I've not ever really used standard Pascal.  Have you?
  1829. I doubt it.  "Standard" Pascal - as originally proposed by Niklaus Wirth in
  1830. "Pascal User Manual and Report" - is (IMHO) commercially unviable, nor was
  1831. it intended to be so.  Also to my knowledge there is no compiler available
  1832. on the MS-DOS PC platform that is absolutely "standard".  This is primarily
  1833. because of the foregoing and because no true standard really existed until
  1834. recently and even then I believe it may still be only an ANSI draft.  
  1835.  
  1836. I have seen an ISO standard referred to in advertisements but have never been
  1837. able to find any documentation as to what it is!  Of course that does not
  1838. mean it does not exist! :-)
  1839.  
  1840. I believe VAX Pascal might have a compiler directive or warning when non-standar
  1841.  enhancements are used.  Others would know this far better than me.
  1842.  
  1843. The ability to use get and put can be obtained by writing them yourself and
  1844. placing them in their own unit for future use.
  1845.  
  1846. TeeCee
  1847.  
  1848.  
  1849. --- TC-ED   v2.01  
  1850.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1851.  * Tossed by SFToss v1.00b on 92/03/27  23:27:03
  1852.  
  1853. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1854.  
  1855. Conference 4
  1856. Date       03-27-92 08:26:43
  1857. From       Trevor Carlsen
  1858. To         Jud Mccranie
  1859. Subject    Re: Reading from a text f
  1860.  
  1861.  
  1862.  
  1863.  TC> The trouble with using a method like this is that it will not
  1864.  TC> work unless the text files have no lines exceeding 80
  1865.  TC> characters and the text being searched for does not span any
  1866.  TC> line.  Far better to use an algorithm such as Boyer-Moore and
  1867.  TC> search the complete file rather than lines.
  1868.  
  1869.  JM> Yes, no, and maybe.  It depends on the format of the file (line
  1870.  JM> length, file size, etc).  There are other things to consider too.
  1871.  JM> For instance, are you going to search through the file once only,
  1872.  JM> or are you going to make several searches in the same file.
  1873.  
  1874.  JM> Also, the obvious method is good enough for most real cases...
  1875.  
  1876. A great many text files are not produced using TP. 
  1877.  
  1878. How would you go about finding every reference to yourself in a file - say
  1879. the text portion of a Pascal conference message.  Your method will not work
  1880. infallibly because some reader/editors still comply with the FidoNet standard
  1881. that says CR/LFs should be used ONLY to designate end of paragraph and not
  1882. EOLN.  If your name was more than 255 characters into a paragraph, it would
  1883. be missed altogether. 
  1884.  
  1885. TeeCee
  1886.  
  1887. --- TC-ED   v2.01  
  1888.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1889.  * Tossed by SFToss v1.00b on 92/03/27  23:27:03
  1890.  
  1891. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1892.  
  1893. Conference 4
  1894. Date       03-27-92 08:13:51
  1895. From       Dj Murdoch
  1896. To         Albert Ng
  1897. Subject    Re: giant Const in Pascal
  1898.  
  1899.   AN> This is an old question but somehow I missed the solution..
  1900.  
  1901.  AN> I want to declare a constant like this:
  1902.  
  1903.  AN>   CONST
  1904.  AN>     BitMap:ARRAY[1..2000] of BYTE = (1,2,3,4......)
  1905.  
  1906.  AN> As you see that's will take million years to write this 
  1907.  AN> statment, any suggestion ? it's similar to the SELF-Modify 
  1908.  AN> EXE problem, and converting the
  1909.  AN> Bitmap into OBJect file and {$L} may help.
  1910.  AN> may help
  1911.  
  1912. If you don't need to be able to edit it, then use BINOBJ and link a binary
  1913. copy of the bitmap in directly.  If you do need to edit it, write a little
  1914. program to read or generate the binary copy, and write out the CONST statement
  1915. to a file.  It's not hard.
  1916.  
  1917. --- Msg V3.2
  1918.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1919.  * Tossed by SFToss v1.00b on 92/03/28  09:11:09
  1920.  
  1921. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1922.  
  1923. Conference 4
  1924. Date       03-27-92 08:16:53
  1925. From       Dj Murdoch
  1926. To         Cowan Dubose
  1927. Subject    Re: error 204  invalid pointer operation
  1928.  
  1929.   CD> In my program when it gets to a line that uses the dispose 
  1930.  CD> procedure it produces error 204  Invalid Pointer 
  1931.  CD> Operation.  In the manual it says that this can be caused 
  1932.  CD> if the pointer is nil which I know it isn't because I put 
  1933.  CD> an IF statement before it disposes the pointer that prints 
  1934.  CD> 'nil' if it's nil and 'not nil' if it's not.
  1935.  
  1936. It can also happen if the pointer isn't in the heap.  If you've somehow assigned
  1937. a value to it (either intentionally or not) by some method other than New
  1938. or GetMem, you shouldn't Dispose it.
  1939.  
  1940.  CD>    The other thing that can cause this error according to 
  1941.  CD> the manual is "the free list can not be expanded due to  a 
  1942.  CD> full free list or to  heapPtr being to close to the bottom 
  1943.  CD> of the free list."  What does that mean?
  1944.  
  1945. Read about the free list.  This means that it's full.
  1946.  
  1947. --- Msg V3.2
  1948.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1949.  * Tossed by SFToss v1.00b on 92/03/28  09:11:09
  1950.  
  1951. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1952.  
  1953. Conference 4
  1954. Date       03-28-92 00:34:14
  1955. From       Trevor Carlsen
  1956. To         david begley
  1957. Subject    TP 6 Bad design
  1958.  
  1959.  
  1960.  
  1961.  db> Don't forget that the command line compiler *sometimes* (due to fewer 
  1962.  
  1963.  db> memory constraints) produces smaller and faster code than the IDE 
  1964.  db> (even when compiling to an .EXE).
  1965.  
  1966. Interesting.  Are you sure of this, or better still, can you post a demonstratio
  1967.  of this?  I have always thought that the code produced by the IDE compiler
  1968. was identical to that produced by the command line version.  In fact, I thought
  1969. that the "two" compilers were identical except that one was wrapped in a shell.
  1970.  
  1971. TeeCee
  1972.  
  1973. --- TC-ED   v2.01  
  1974.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1975.  * Tossed by SFToss v1.00b on 92/03/28  18:07:31
  1976.  
  1977. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1978.  
  1979. Conference 4
  1980. Date       03-28-92 01:38:54
  1981. From       Trevor Carlsen
  1982. To         Joy Mukherjee
  1983. Subject    Re: Qwk Format/reader 1/3
  1984.  
  1985.  
  1986.  
  1987.  MO>        this is another example of the problem, 2/3 et 3/3
  1988.  MO> never made it here. Could you repost please ???
  1989.  
  1990.  JB> Same here.. we just got 1/3 also.. *PLEASE* repost, Joy! :)
  1991.  
  1992. Joy it appears that some poorly designed mail tossers are incapable of detecting
  1993. differences in a subject line that occur after about the first 10-15 characters.
  1994.  To ensure these do not consign your messages to that large bit bucket in
  1995. the sky put the 1/3, 2/3 etc first!
  1996.  
  1997. (I just found about this myself!)
  1998.  
  1999. TeeCee
  2000.  
  2001. --- TC-ED   v2.01  
  2002.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2003.  * Tossed by SFToss v1.00b on 92/03/28  18:07:31
  2004.  
  2005. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2006.  
  2007. Conference 4
  2008. Date       03-28-92 09:18:55
  2009. From       Trevor Carlsen
  2010. To         Jud Mccranie
  2011. Subject    Power of assemb vs Pascal
  2012.  
  2013.  
  2014.  
  2015.  JM> told him I'd write a Pascal proc to do it, and send him the
  2016.  JM> Pascal source and the exe so he could see how to do it.  It was
  2017.  JM> an almost-trivial program in Pascal, using recursion.  I know
  2018.  JM> assembler must be able to do recursion, but probably not easily.
  2019.  
  2020. As assembler is so low-level, recursion is handled by the programmer and the
  2021. stack is used.  As this is exactly what is happening anyway, it is no different,
  2022. and no more difficult, than normal assembler programming.
  2023.  
  2024. Your assembly "programmer" friend is obviously not very competent in programming
  2025.   Programming is not just about writing code, it is also about solving problems
  2026. and creativeness.
  2027.  
  2028. TeeCee
  2029.  
  2030. --- TC-ED   v2.01  
  2031.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2032.  * Tossed by SFToss v1.00b on 92/03/28  18:07:31
  2033.  
  2034. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2035.  
  2036. Conference 4
  2037. Date       03-28-92 09:34:50
  2038. From       Trevor Carlsen
  2039. To         Thomas Roes
  2040. Subject    Int 8 & disk-operaties
  2041.  
  2042.  
  2043.  
  2044.  TR> Ik heb in een programma een klokje op het scherm staan (het 
  2045.  
  2046. This is an English language echo.  Please re-read the rules and comply.
  2047.  
  2048. Trevor Carlsen
  2049. Moderator.
  2050.  
  2051. --- TC-ED   v2.01  
  2052.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2053.  * Tossed by SFToss v1.00b on 92/03/28  18:07:31
  2054.  
  2055. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2056.  
  2057. Conference 4
  2058. Date       03-28-92 09:36:40
  2059. From       Trevor Carlsen
  2060. To         Frode Lundgren
  2061. Subject    Re: Text Viewer (1 of 3)
  2062.  
  2063.  
  2064.  
  2065.  FL> Oh yes, I really loved this one. Just a few seconds of ReWriting and 
  2066.  
  2067.  FL> it works under TP 5.5, my problem is. Where you write
  2068.  
  2069.  FL> Case Keyword of
  2070.  FL>   Escape : Halt;
  2071.  
  2072.  FL> I've written
  2073.  FL> Case KeyWord of
  2074.  FL>   Escape : begin clrscr; halt; end;
  2075.  
  2076.  FL> But, the screen isn't cleared, why not ?? The DOS PROMPT appears on 
  2077.  FL> 1,2 (x,y), but the screen from the textviewer is still there.. What 
  2078.  FL> have I done wrong ??
  2079.  
  2080. The program sets a window size so all that you would be clearing is the main
  2081. window, the cursor instructions are all that should remain.  To fix, restore
  2082. the window size to full screen before the clrscr procedure is used or (better
  2083. still) put the window restoration and the clrscr call into the exit procedure.
  2084.  This may involve some changing of the compiler directives if you are not
  2085. using TPro.
  2086.  
  2087. TeeCee
  2088.  
  2089.  
  2090. --- TC-ED   v2.01  
  2091.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2092.  * Tossed by SFToss v1.00b on 92/03/28  18:07:32
  2093.  
  2094. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2095.  
  2096. Conference 4
  2097. Date       03-28-92 09:42:00
  2098. From       Trevor Carlsen
  2099. To         Max Maischein
  2100. Subject    Reading from a text f
  2101.  
  2102.  
  2103.  
  2104.  > The trouble with using a method like this is that it will not work
  2105.  > unless the text files have no lines exceeding 80 characters and
  2106.  > the text being searched for does not span any line.  Far better to
  2107.  > use an algorithm such as Boyer-Moore and search the complete file
  2108.  > rather than lines.
  2109.  
  2110.  MM> But how do you skip the CR/LF sequences in the searched text ??
  2111.  MM> I assume that you proposed to read a 64K chunk of text in, and then
  2112.  MM> do a BMSearch. Do you write a procedure like 'GetChar', that delivers 
  2113.  
  2114.  MM> the ( cleaned up ) next char, skipping CR / LFs, 80h 0Ch sequences and 
  2115.  
  2116.  MM> so on ??
  2117.  
  2118. Why do you need to skip them?  If the text being searched for spans a line
  2119.  (has a CR/LF sequence imbedded in it), neither method is going to find it.
  2120.  However the file search using BM is still better and very much faster because
  2121. it will find instances in files produced by text editors that only use CR/LFs
  2122. to denote paragraph end.  It also can be used on binary files.
  2123.  
  2124. TeeCee
  2125.  
  2126. --- TC-ED   v2.01  
  2127.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2128.  * Tossed by SFToss v1.00b on 92/03/28  18:07:32
  2129.  
  2130. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2131.  
  2132. Conference 4
  2133. Date       03-28-92 09:58:04
  2134. From       Trevor Carlsen
  2135. To         Jim Thorpe
  2136. Subject    M2 - Modula-2
  2137.  
  2138.  
  2139.  
  2140. Jim, the subject matter of this conference is Pascal - not Modula-2.  Please
  2141. take this thread to netmail.  The person you addressed this message to will
  2142. not see your message anyway as his access to this conference has been withdrawn.
  2143.  
  2144. Trevor Carlsen
  2145. Moderator.
  2146.  
  2147. --- TC-ED   v2.01  
  2148.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2149.  * Tossed by SFToss v1.00b on 92/03/28  18:07:32
  2150.  
  2151. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2152.  
  2153. Conference 4
  2154. Date       03-28-92 10:08:16
  2155. From       Trevor Carlsen
  2156. To         Albert Ng
  2157. Subject    giant Const in Pascal
  2158.  
  2159.  
  2160.  
  2161.  AN> I want to declare a constant like this:
  2162.  AN>   CONST
  2163.  AN>     BitMap:ARRAY[1..2000] of BYTE = (1,2,3,4......)
  2164.  AN> As you see that's will take million years to write this statment...
  2165.  
  2166. As a typed constant is really only an initialised variable anyway, just change
  2167. BitMap to a variable and initialise it in a loop.
  2168.  
  2169. TeeCee
  2170.  
  2171. --- TC-ED   v2.01  
  2172.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2173.  * Tossed by SFToss v1.00b on 92/03/28  18:07:32
  2174.  
  2175. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2176.  
  2177. Conference 4
  2178. Date       03-28-92 10:15:27
  2179. From       Trevor Carlsen
  2180. To         Cowan Dubose
  2181. Subject    error 204  invalid pointer operation
  2182.  
  2183.  
  2184.  
  2185.  CD> In my program when it gets to a line that uses the dispose procedure 
  2186.  
  2187.  CD> it produces error 204  Invalid Pointer Operation.  In the manual it 
  2188.  CD> says that this can be caused if the pointer is nil which I know it 
  2189.  CD> isn't because I put an IF statement before it disposes the pointer 
  2190.  CD> that prints 'nil' if it's nil and 'not nil' if it's not.
  2191.  CD>    The other thing that can cause this error according to the manual 
  2192.  
  2193.  CD> is "the free list can not be expanded due to  a full free list or to  
  2194.  
  2195.  CD> heapPtr being to close to the bottom of the free list."  What does 
  2196.  CD> that mean?
  2197.  
  2198. You have come across an error in the TP6 manual.  There is no free list in
  2199. TP6, it was discontinued when the method of memory management for the heap
  2200. was changed in TP6.  However if you are using TP4 to 5.x then this is valid.
  2201.  
  2202. Assuming that you are not using TP6 and if your program does a lot of allocating
  2203. and deallocating of dynamic variables, you may have to rethink your strategy
  2204. as regards the disposing of variables.  This is a little complex to discuss
  2205. in any detail here without knowing more about your problem.
  2206.  
  2207. Another thing that may be worth checking is that you have range checking enabled
  2208. as a similar effect can be achieved by out-of-bounds writes trashing the ExitPro
  2209.  and ExitCode initialised variables in the system unit.
  2210.  
  2211. TeeCee
  2212.  
  2213. --- TC-ED   v2.01  
  2214.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2215.  * Tossed by SFToss v1.00b on 92/03/28  18:07:32
  2216.  
  2217. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2218.  
  2219. Conference 4
  2220. Date       03-28-92 10:28:15
  2221. From       Trevor Carlsen
  2222. To         Michael George III
  2223. Subject    HELP! HELP! HELP!
  2224.  
  2225.  
  2226.  
  2227.  MG>   FlagRecSet = SET OF Filerec; {Set of file flags}
  2228.  
  2229.  MG> { ERROR }   s.Flag := Notvalidated;
  2230.  
  2231.  MG> NOTE THE LINE THAT HAS the {ERROR} before it.. Why doesn't this line 
  2232.  
  2233.  MG> compile? I get an error message that says "DATA TYPES DON'T MATCH"? 
  2234.  
  2235. s.Flag is defined as a set.  NotValidated is a set element and therefore incompa
  2236. ible.
  2237.  
  2238. Fix:
  2239.   s.Flag := [NotValidated];   or if it is desired to not alter any of the
  2240. other flags in the s.Flag set -
  2241.   s.Flag := s.Flag + [NotValidated];
  2242.  
  2243. TeeCee
  2244.  
  2245. --- TC-ED   v2.01  
  2246.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2247.  * Tossed by SFToss v1.00b on 92/03/28  18:07:32
  2248.  
  2249. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2250.  
  2251. Conference 4
  2252. Date       03-27-92 17:00:00
  2253. From       Norbert Igl
  2254. To         Jud Mccranie
  2255. Subject    INPUT ROUTINE/LIMITED LENGTH--CORRECTION
  2256.  
  2257.  
  2258.  
  2259.  
  2260.  > Hello, Hec
  2261.   I'm not Hec, sorry ?...
  2262.  > I am choosing this way to communicate with you this time --- via
  2263.  > Bluewave, your nearest competitor, to attempt to find out if the beta
  2264.  > version for the new Xpress door is anywhere near completion yet.
  2265.  > I would like to be able to carry both doors on my system.
  2266.  > I am working on getting hooked up with Fidonet so that we may
  2267.  > communicate more directly with each other in the future.
  2268.  > Regards, Rich
  2269.  ...and i have no idea what you're talking about ?
  2270.   ???  EchoMail... got it's own rules and ways... ???
  2271.  
  2272. Bye from Germany, Norbert
  2273.  
  2274. ---
  2275.  * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  2276.  * Tossed by SFToss v1.00b on 92/03/28  22:29:04
  2277.  
  2278. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2279.  
  2280. Conference 4
  2281. Date       03-27-92 17:25:00
  2282. From       Norbert Igl
  2283. To         Gerald Gutierrez
  2284. Subject    Record Const..
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  > Can someone perhaps point out the problem to the follow declaration ?
  2291.  
  2292.  >     Const
  2293.  >       MainMenu : MenuOptionsType =
  2294.  >                (   TxtAttr      : 7,
  2295.  >                    PrefixAttr   : 15,
  2296.  [...]
  2297.  >                                    'ASCII Protocol'),
  2298.  >                    StartOpt     : 1
  2299.  >                );
  2300.  
  2301.  > This is probably just another stupid mistake, but I don't see
  2302.  > anything wrong at the moment and as far as I know, that is the method
  2303.  > by which constants that rule with a record structure are supposed to
  2304.  > be set up. Thanks for any help !
  2305.  
  2306.   Hi Gerald,
  2307.  
  2308.   Constant-Records are defined as follows : ( example )
  2309.  
  2310.   Type  DemoType = Record
  2311.            First  : Byte;
  2312.            Second : Word;
  2313.            Third  : Array[1..2] of String;
  2314.            Foutrh : real;
  2315.         end;
  2316.  
  2317.   Const
  2318.       DemoConst : Demotype =
  2319.       ( Frist : 1;
  2320.         Second: 2;
  2321.         Third : ('Third-1,'Third-2);
  2322.         fourth; 3.14   { <--   no ";" here ! ( at my TP6.0 ?) }
  2323.       );
  2324.  
  2325. ---
  2326.  * Origin: Let's talk about hex, baby.... (2:241/5300.3)
  2327.  * Tossed by SFToss v1.00b on 92/03/28  22:29:04
  2328.